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PREFACE 



The Basics provides an explanation of multilevel security (MLS) 
technology and its operational capabilities for program managers, 
action officers, and others who are faced with the task of 
determining if and how MLS technology could be beneficial in 
their information systems. It contains a set of MLS Dos and Don'ts 
that can guide readers in their pursuit of MLS capabilities. 



This document also introduces the Department of Defense (DoD) 
MLS Program. In addition to the program's mission and goals, this 
document describes the primary MLS capabilities that the program 
is developing and deploying. 



This document consists of four sections and an appendix. Section 1 
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introduces MLS. Section 2 discusses the DoD MLS Program. 
Section 3 discusses the concepts associated with MLS and 
introduces the basic MLS technologies that can provide MLS 
capabilities. Section 4 offers guidance for greater success in 
achieving MLS capabilities. The appendix presents a short list of 
acronyms. 

TABLE OF CONTENTS 
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INTRODUCTION 
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A significant challenge exists throughout the Department of 
Defense (DoD) in getting mission-critical and time-sensitive 
information into the hands of people who need it. All too often, the 
information resides in information systems that do not provide 
access to persons outside the immediate community of interest. 



The DoD relies on information systems to support the missions of 
nearly every organization. In most cases today, information is 
protected at the highest classification level of the data in the 
system, the system-high level. Thus, the information is not readily 
accessible by persons not cleared to the system-high level, even 
though the information being sought may be of a lower 
classification level and thereby releasable to the requester. 
Operating information systems in this manner often results in the 
over-classification of data, over-clearing of personnel, and system 
redundancies and inefficiencies. This situation commonly exists 
throughout the DoD. What is needed is a means by which the 
actual security level of the information can be maintained and 
information can be appropriately protected, processed, and 
distributed. Users also need timely access to the data and the 
various processing and communications resources that they require 
to accomplish their jobs. 



The security constraints imposed by the system-high 
mode of operation on DoD information systems often result in less 
than effective operations. For example, tape, disk, and paper copy 
output are often manually reviewed, downgraded, and transferred 
through time-consuming and labor-intensive procedures among 
systems operating at different security levels. This method of data 
transfer is often inefficient and ineffective. It can also result in the 
inefficient use of personnel and resources, a condition that 
challenges the current downsizing requirements facing many 
government organizations. 

In addition, staff members need to access and fuse data and other 
resources currently available on several systems to perform their 
duties. Each system generally has its own interface (e.g., via a 
specific set of terminals or workstations), requiring multiple 
terminals that take valuable space in command centers, offices, and 
computer rooms. Also, significant time and effort are needed to 
manually fuse data from different sources. 



The maintenance of redundant data bases is another unfavorable 
condition that results from using separate systems for each security 
level. Often a separate data base must be created and maintained for 
each security level processed. The use of these multiple data bases 
presents several operational problems. First, it fragments 
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information. A collection of information regarding a specific event 
may be split across multiple systems of different security levels. 
Incomplete or misleading information may result unless pertinent 
data can be obtained from all related systems. Second, information 
of a lower classification may be unnecessarily upgraded in the 
higher level systems, resulting in its over-classification and 
consequent limited access. As a result, duplication and multiple 
classifications of the same information occurs. Third, the 
maintenance of multiple data bases is staff intensive and depletes 
other system resources. Because the data may change continually, 
updating data bases often results in inconsistent views of the 
current information across different levels. The constantly changing 
nature of the data, combined with human updating, often results in 
outdated information at one or more of the security levels. 

Another difficulty when multiple systems operate at different 
security levels is the inability to share the computer and 
communication system infrastructures, such as cabling, network 
components, printers, workstations, and hosts. If sharing these 
resources were possible, equipment, operations, and maintenance 
costs would decrease. 



Multilevel security, or MLS, is a capability that allows 
information with different sensitivities (i.e., classification and 
compartments) to be simultaneously stored and processed in an 
information system with users having different security clearances, 
authorizations, and needs to know, while preventing users from 
accessing information for which they are not cleared, do not have 
authorization, or do not have the need to know. MLS capabilities 
often can help overcome the operational constraints imposed by 
system-high operations and can foster more effective operations. 
For example, systems once separated by an airgap or connected 
only by a sneaker net may be electronically interconnected by an 
MLS guard, allowing the data transferred to be current rather than 
merely historical in value. 

Additionally, staff members who once had to use several 
different terminals for day-to-day operations may now access the 
systems they need from an MLS workstation, allowing a single, 
secure interface to the systems they use. 

MLS guards and MLS workstations can be used to bridge security 
boundaries between existing single-level systems. Ideally, 
information systems themselves will become MLS systems to 
provide more integrated multilevel capabilities for users. MLS 
hosts, MLS networks, and MLS data base management systems 
(DBMS) can provide common data processing and data transfer 
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platforms to serve as the foundation for MLS systems. A larger 
community that once may have been segregated for security reasons 
may be electronically integrated to more effectively and efficiently 
execute its collective mission. 



MLS technology is real and in use today. As the technology evolves 
with the computer and communications industry, its capabilities 
will provide the DoD with increasing mission effectiveness. MLS is 
a significant enabling technology for command, control, 
communications, and intelligence systems because it enhances the 
availability of information while maintaining security. For this 
reason, it is important to understand what capabilities MLS can 
provide and to integrate those capabilities into DoD information 
systems now and into the next century. 

THE DoD MLS PROGRAM 



The DoD MLS Program provides a focal point within the DoD to 
promote the development and implementation of MLS solutions for 
information systems. The mission of the program is to expedite the 
fielding of MLS capabilities in the DoD. The goal of the program is 
to develop, acquire, and deploy solutions and technologies that will 
allow the DoD to meet operational requirements for MLS in its 
automated information systems. The program accomplishes this 
goal through the following activities: 



*Planning, coordinating, reviewing, and assessing MLS efforts 
throughout the DoD to provide synergy and to reduce duplication 
of effort 



*Developing and assessing MLS technology for widespread 
application through approved architectures 

*Providing engineering assistance to the DoD to expedite the 
transfer of MLS capabilities from testbeds to operational systems 

The program is managed by the Defense Information Systems 
Agency/Joint Interoperability and Engineering Organization/Center 
for Information Systems Security, with the sponsorship and 
oversight from the Assistant Secretary of Defense for Command, 
Control, Communications, and Intelligence and the Joint Staff The 
National Security Agency (NSA) is the security technical 
coordinator for the program, and the Defense Intelligence Agency is 
the intelligence coordinator. This combination brings the resources 
and capabilities of the key DoD information systems security 
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(INFOSEC) organizations together to meet the challenges faced 
when developing and deploying MLS capabilities. 

The DoD MLS Program provides the following products, services, 
and capabilities to DoD organizations. 

Technology Surveys and Assessments. Technical and operational 
assessments of the MLS marketplace and its utility. 

Surveys and Assessments Available Today 

* Trusted Workstation Survey and Assessments 
*Xerox Encryption Unit Assessment 

*Loral Multinet Gateway MLS- 100 Assessment 

* Secure Network Demonstration 
*SecureWare MaxSix Assessment 

Surveys and Assessments Scheduled for Fiscal Year (FY) 94 
Trusted Host and Workstation Survey 
♦Trusted DBMS Survey 

* Trusted Network Survey 
*MLS Guard Survey 

MLS Solution Sets. A set of government off-the-shelf and 
commercial off-the-shelf near-term solutions to common 
requirements for MLS (discussed in greater detail in Section 3.4): 

* Standard Guards 

♦Operations (OPS)/Intelligence (INTEL) Interfaces 
*MLS Workstations. 

System Security Profiles. A repository of security-related 
assessments of MLS products and configurations to streamline the 
certification of MLS solutions. These profiles draw on previously 
tested, assessed, and evaluated configurations to assist in the 
system certification and accreditation process. 
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MLS Assistance. A wide range of MLS technical and programmatic 
support to DoD organizations: 

♦MLS requirements analysis, solution identification, security 
policy definition, and concept of operations development 

* Certification and accreditation planning, analysis, and testing 

♦Project review and other consultation (e.g., MLS help desk). 



MLS Deployments. Installation and integration of MLS solution 
sets at the Unified Commands and other high-priority commands. 



MLS Demonstration and Assessment Center. A facility dedicated 
to investigating the application of MLS products and technology to 
fulfill DoD operational requirements. The MLS Demonstration and 
Assessment Center: 



♦Assesses existing emerging MLS products and technology 
♦Advances new approaches to MLS 

♦Provides a neutral demonstration environment for MLS vendors 
♦Maintains a DoD-wide perspective on MLS solutions. 



The DoD MLS Program provides solutions to resolve 
interoperability problems between existing system-high 
environments. The program offers expertise, technologies, and 
capabilities to help DoD organizations solve similar problems. 



THE MLS ENVIRONMENT 

This section defines characteristics and components of the MLS 
environment. It explains the operational requirements for MLS 
technology and the problems the DoD faces with its current 
systems. It explores potential MLS solutions, emphasizing the need 
to implement an incremental approach that builds toward a full 
MLS capability. 



Multilevel security allows information systems to provide 
capabilities that augment its existing single-level data processing 
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and data communications services. Data of multiple security levels 
are processed and transferred by the system, which also separates 
the different security levels and controls access to the data. 
Applications are provided, much in the same way that they exist 
today, so that users can access, process, modify, store, and transfer 
data. For example, office automation (e.g., word processing, 
electronic filing, spreadsheets), data base management, data fusion, 
modeling and simulation, briefing and display, command and 
control, and decision support applications are needed as much in an 
MLS system as they are in existing single-level systems. Some 
applications process only one level of data at a time, such as when 
a user edits a document with a word processing tool. In this case, 
the data in the document are treated as if they were a single level, 
the classification of the document itself. More complex 
applications could be provided that treat individual data elements at 
their actual levels. For example, a word processor could enforce 
paragraph and page labels, or an MLS data base could bring 
together data elements of different security levels to allow an 
analyst a multilevel view of the information. 

With the concept in mind that MLS systems can provide 
capabilities similar to existing, single-level applications, but for 
data of multiple security levels, one can understand the multilevel 
mode of operation and the basic building blocks that form MLS 
systems. 



3 .1 MULTILEVEL MODE OF OPERATION 



In the DoD, a system's security operations are characterized 
according to minimum user clearances and the maximum security 
levels of data either processed or transferred by the systems. 
According to these characteristics, the DoD defines the following 
four modes of operation: 



Dedicated System high Partitioned (or compartmented) 
Multilevel. 



Restrictions on the user clearance levels, formal authorization 
requirements (i.e., for access to special access programs, 
compartmented information, and other close-hold data), need-to- 
know requirements, and the range of sensitive information 
permitted on the system are inherent in each of these security 
modes. The following chart illustrates the characteristics of each 
mode of operation. 
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As one progresses from the dedicated arid system high modes to the 
partitioned and multilevel modes, there is a shift from providing 
security using physical controls, administrative procedures, and 
personnel security to using computer security, communications 
security, and trusted system techniques. Each mode of operation 
requires the use of security features to provide the required level of 
protection. The dedicated mode (where all users possess clearance 
levels greater than or equal to the highest level of data to be 
processed, all users have formal authorization, and all users have 
the need to know for the data) has the fewest security requirements, 
followed by system high, then partitioned and multilevel, which 
require the most security protection because there is an increasing 
risk that insufficiently cleared persons may gain access to data for 
which they lack authorization. 

When a system operates in the multilevel mode, it allows data of 
two or more security levels to be processed simultaneously when 
not all users have the clearance, formal authorization, or need to 
know for all data handled by the system. The system is able to 
separate and protect the data according to these restrictions. 

To amplify the definition, an MLS system might process both 
Secret and Top Secret collateral data and have some users whose 
maximum clearance is Secret and others whose maximum clearance 
is Top Secret. Another MLS system might have all its users cleared 
at the Top Secret level, but have the ability to release information 
classified as Secret to a network consisting of only Secret users and 
systems. Still another system might process both Secret and 
Unclassified information and have some users with no clearance. In 
each of these instances, the system must implement mechanisms to 
provide assurance that the system's security policy is strictly 
enforced. In these examples, the policy allows access to the data by 
only those users who are appropriately cleared and authorized (e.g., 
having formal access approval) and who have an official need to 
know for the data. 



A related mode of operation is the partitioned mode, also known as 
compartmented mode. Although similar concepts and solutions are 
involved for compartmented mode operations as are for the 
multilevel mode, there is also a key difference. In the 
compartmented mode, all users have clearances for all the data 
processed but may not have authorizations for all the data; whereas 
for multilevel mode, some users may not even be cleared for the 
highest level. Because the compartmented mode is often envisioned 
for the intelligence community, all such users would have Top 
Secret security clearances and often authorizations for one or more, 
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but possibly not all, compartments in the system. 

DoD security regulations state that systems must receive approval 
to operate (in a particular mode) from their accreditation 
authorities. This approval is also known as an accreditation and 
indicates that the cognizant authorities have accepted the evidence 
that the system has sufficient features and assurance to allow 
operations while maintaining an acceptable level of risk. Only 
certain trusted technology provides the features and assurances 
required by the accreditation authorities for multilevel mode 
operations. The next section focuses on that technology. 



3.2 TRUSTED COMPUTER SYSTEM EVALUATION 
CRITERIA 



The trusted computer system evaluation criteria defined in DoD 
5200.28-STD, also known as the Orange Book because of its bright 
orange cover, classifies systems into four broad hierarchical 
divisions of increasing security protection. The criteria provide the 
basis for evaluating the effectiveness of the security controls built 
into the products used in information systems. 

The criteria were developed to provide users a measure with which 
to assess the degree of trust that can be placed in computer systems 
for the secure processing of classified or other sensitive 
information. In general, secure systems will control, through the 
use of specific security features, access to data such that only 
properly authorized individuals, or processes operating on their 
behalf, will have access to read, write, delete, or execute data. 



The criteria are divided into four divisions — D, C, B, and A — 
ordered in a hierarchical manner with the highest division (A) 
reserved for systems providing the most comprehensive security. 
Each division represents a major increase in the overall confidence, 
or trust, that one can place in the system. Successive levels of trust 
build upon and incorporate the criteria of the previous lower level 
of trust. 



Within Divisions C and B there are a number of subdivisions 
known as classes. The classes are also ordered in a hierarchical 
manner with systems representative of Divisions C and B 
characterized by the set of computer security mechanisms that they 
possess. For Division C, so called discretionary protection is 
provided, whereby users can grant or deny access by other users 
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and groups of users to the system resources that the users control. 
For Division B, mandatory protection is provided that, in 
conjunction with the discretionary protection, institutionalizes 
hierarchical access controls that can be used to separate and protect 
data of different security levels. Division A also provides the 
mandatory protection features. 



Systems representative of the higher classes in Division B and 
Division A derive their security attributes more from their design 
and implementation structure than merely security features or 
functionality. Increased assurance that the required features are 
operative, correct, and tamperproof under all circumstances is 
gained through progressively more rigorous design, 
implementation, and analysis during the development process. 
Division A requires formal (e.g., mathematical) design and 
verification techniques to provide increased assurances over 
Division B. 



Four major sets of criteria apply to each class. The first three sets 
represent features necessary to satisfy broad control objectives of 
security policy, accountability, and assurance. The fourth set, 
documentation, defines the type of written information such as user 
guides, manuals, and the test and design documentation required 
for each class. 



MLS capabilities are associated with Division B and A products. In 
these classes, security mechanisms are in place to ensure that only 
authorized users with clearances and need to know can access the 
data. Assurances to increase confidence that the mechanisms are 
functioning securely increase in the higher classes; B2, B3, and Al 
class components offer progressively more assurance than do B 1 
class components. The following table summarizes the key 
characteristics of each class. The security requirements increase as 
the division and class increase. The dashed line shows division 
where MLS capabilities are introduced into the criteria (i.e., in 
divisions A and B). The reader should explore DoD 5200.28-STD 
for more information on the levels of trust. 



Division Class Title Key 
Charact. 

D N/A Minimal Protection None (a rating given to products 
that do not meet all of the criteria 
of another class) 
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C CI Discretionary Security Protection Discretionary Access Control, User 
Authentication 

C2 Controlled Access Protection All of CI, plus Audit Trails, Individual 
Passwords, Object Reuse 



B Bl Labeled Security Protection All of C2, plus Labels, Mandatory Access 
Control, Informal Security Policy Model 

B2 Structured Protection All of Bl, plus Structured Trusted Computing 
Base (TCB), Trusted Path, Covert Channel 
Analysis, Penetration Resistance, Configurati 
Management 

B3 Security Domains All of B2, plus Formal Security Policy 
Model, Minimal and Tamperproof TCB, Trusted 
Recovery, Substantial Documentation 

A Al Verified Design All of B3, plus Formal Specification, 
Formal Design Verification, Trusted Distributn 



The NSA has also published interpretations of the trusted systems 
criteria that apply to other components such as networks, data base 
management systems, and other computer subsystems. The levels of 
trust defined in DoD 5200.28-STD, however, are not directly 
applicable to systems, but solely to components in systems. 
Products that the NSA has evaluated and that meet these criteria are 
recorded in the Evaluated Products List in NSA's Information 
Systems Security Products and Services Catalogue, which is 
updated and published quarterly. 



Not all MLS products are formally evaluated and placed on the 
Evaluated Products List. However, most MLS products are built 
according to the DoD 5200.28-STD criteria or an interpretation, 
and some measure of assurance may be derived for those products 
as well. 



3.3 MLS CONCEPT OF OPERATIONS 



The introduction of MLS capabilities in an existing organization 
will result not only in changes in effectiveness and security of 
operations, but also in the manner business is conducted using 
information systems. MLS affects business processes in many 
ways, from providing users with multilevel views of data that they 
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previously accessed separately, to maintaining electronic sensitivity 
labels (e.g., classification markings, handling restrictions) on data 
that are processed and transferred by the system. Although the 
specific effects MLS technology has on the manner in which users 
work will depend on numerous factors (e.g., the specific technology 
used, the specific application software applied, and the business 
processes themselves), the general impact of MLS on operations is 
summarized as follows: 



Sensitivity Labels. All data must be properly labeled as to 
their classification and other handling restrictions if an MLS 
system is to properly control access to the data. In system-high 
operations, a user may create data (e.g., create a message on a word 
processor) that have security levels equal to or less than the system- 
high level, but all data must be protected at the system-high level 
until they are reliably reviewed for their actual classification and 
removed from the system. In many MLS systems, users make 
decisions at login time as to the security level at which they want to 
operate, knowing that files created during the session will be 
labeled according to their session security level. In MLS systems 
with multilevel windowing capabilities, the user must also make 
conscious decisions as to the security level of data at the time of 
the data's creation, rather than afterwards*****. This type of 
decision needs to be made often, for example, when composing an 
electronic mail message, creating a document, entering data into a 
data base, and creating graphs and charts. 



In the partitioned or compartmented mode, information labels are 
companions to sensitivity labels. Where sensitivity labels indicate 
the overall classification of a data container, such as a file or a 
window on the computer screen, information labels represent the 
actual security level of the data within the container. Access control 
decisions (e.g., whether a user is allowed to access a file) are made 
based on sensitivity labels; information labels are referenced by 
users to determine the actual classification of the data viewed. 



Multilevel Processing. MLS systems offer users the ability to 
process and transfer data of more than one security level while 
maintaining control of the data according to their sensitivity. Users 
could, for example, edit a Secret document, then edit an 
Unclassified document as part of a continuous session. In other 
cases, users may access multilevel data bases and have access to the 
information contained in them according to their security level. For 
example, an uncleared user may have access to only the 
Unclassified portions of a data base, while a Secret-cleared user 
may have access to Secret portions in addition to the Unclassified 
portions. Users would be able to share more synchronous and 
consistent information when multilevel data bases allow currently 
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segregated collections of data to be securely combined. In general, 
multilevel processing capabilities will allow access to multiple 
levels of data from a single work position and use of a common set 
of data processing tools (e.g., word processors, decision support 
tools, data base management systems). 

Planners considering MLS capabilities must remember that MLS 
does not eliminate the need for physical and personnel security for 
computers, networks, and other components that will process or 
transfer classified data. The components still contain the data in 
their memories and disks, and the data could be compromised if 
adequate physical security was not maintained. 



3.4 POTENTIAL MLS SOLUTIONS 



Achieving an MLS system solution to meet operational needs 
involves determining how to integrate the different stand-alone 
legacy information systems and networks into integrated and 
interoperable information systems. The resulting information 
systems should allow authorized users to simultaneously access 
multiple levels of classified data and to securely gain access to 
classified information originally maintained by the separate stand- 
alone information systems. Achieving this end is not the result of 
an instantaneous action. Attainment of an integrated MLS 
capability is predicated on the completion of the following: 



Developing system capabilities that allow systems, at differing 
classification levels, to interact Developing and acquiring MLS 
technology such as hosts, workstations, data base management 
systems, and networks Developing expertise and techniques for 
securely integrating the different components into MLS systems 
that meet operational requirements. 



All the major components— the hosts, workstations, data base 
management systems, and networks-work together to separate and 
protect data of different security levels (e.g., classifications, 
compartments) from users of differing clearance levels. One 
noteworthy aspect of an MLS architecture is that not all 
components need to be trusted. Therefore, a typical system needing 
MLS capabilities might have only a few trusted components with 
the remainder being single level. This combination allows a more 
optimal balance between security and functionality to be achieved. 
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Successfully reaching such an MLS solution requires a strategy. 
The strategy for achieving an MLS capability requires an 
incremental approach that reduces development risks. Shown below 
is a recommended implementation strategy for integrating MLS 
capabilities to meet operational requirements. 

Each increment introduces components that provide additional 
MLS capabilities. Together these components will construct MLS 
systems that allow for the processing of data of multiple 
classifications while providing the assurance that users of differing 
clearance levels only have access to data for which they possess the 
clearance, authorization, and need to know. Discussions of each of 
the component technologies follow. 



3 .4.1 MLS Hosts 



An MLS host is the primary multiuser component of an MLS 
system. MLS hosts are the basic building blocks of MLS systems, 
and as such perform a variety of data processing and data transfer 
services, from functioning as file servers, mail servers, and print 
servers to serving as the platforms for system applications such as 
command and control systems, data base management systems, and 
decision support systems. MLS hosts are compositions of trusted 
operating systems running on any variety of hardware platforms, 
such as microcomputers, minicomputers, and mainframe computers. 
Several products have been evaluated by the NSA that can serve as 
MLS hosts and are currently available. 

The operational value of MLS hosts derives from some high- 
assurance products available to serve MLS systems. High-assurance 
MLS hosts could be used to allow wide ranges of classified data 
and cleared users to access a system (e.g., up to Top Secret data 
with some users uncleared). Some products that could serve as 
MLS hosts, however, are not necessarily high assurance (e.g., some 
are Bl and B2 class products). 



3.4.2 MLS Guards 



MLS guards control the flow of information across security 
boundaries. They are often the initial step toward MLS because 
they can be relatively simple to achieve and can provide some of the 
interconnectivity required to bridge across the security boundaries 
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of existing systems operating at different security levels. Several 
types of guards exist. They might or might not involve human 
review of the data flow and might support data flow in one or both 
directions. Guards generally do not allow full-capability usage of a 
system on one side of the guard by users from the other side, but 
rather support only limited types of data transfers. As previously 
illustrated, MLS guards partially break through the wall of security 
constraints that restrict the flow of data among systems operating at 
different security levels. 

MLS guards can be implemented as one-way filters (e.g., allowing 
low-to-high or high-to-low data flow only) or as bidirectional 
filters for data traffic between systems. Low-to-high guards are 
available today and can be deployed with relatively low 
development risk. Low-to-high guards allow data flow from a lower 
classified system to a higher classified system without data flow in 
the other direction. This capability is useful when users of high 
systems need data from lower systems in electronic form in a timely 
manner. One-way, low-to-high guards may need to prevent the 
transfer of malicious code (e.g., viruses), of forged identifiers, and 
of intentional network flooding attempts that could result in denial 
of service conditions on the high side. Some of these guards have 
been successfully operational in various DoD organizations for 
several years. However, the most effective use of a guard is 
bidirectional, because a two-way flow of data allows more robust 
communication protocols and provides more reliable data transfer. 
For example, a one-way guard provides no receipt or 
acknowledgment for data transfers because such a receipt would 
violate the security policy rule governing the one-way flow of data. 

The rules for high-to-low data flow are often more complex than 
those for low-to-high data flow, because the guards are required to 
enforce complicated and sometimes dynamic security policy (e.g., 
classification rules). Guards can be implemented to check whether 
the data bound for the low system is classified at the low system's 
security level. This check could be executed in several ways, such 
as by ensuring that the data are of a specific content or format, 
ensuring that the data do not contain any defined classified code 
words or phrases (e.g., "dirty words"), or even ensuring that the data 
have a specific sensitivity label. If the checks pass, the guard 
downgrades the data and passes them to the low system. 

Guards can also be implemented to actually change the data (e.g., 
sanitization or downgrading). The guard could accept data from the 
high system and apply specific processes to the data to reduce their 
security levels to that of the low system before it downgrades the 
information and passes it to the low system. A human may be called 
into the process at any point necessary to review specific data and 
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make decisions when the computer is unable. For example, free- 
form text found in electronic mail is beyond the ability of 
computers to check for classification'. Humans may be needed to 
review such data for classification before they are released to the 
low system. 

The ideal guard would be capable of correctly reviewing or 
sanitizing any form and content of data without human 
intervention. We are, however, a long way from that ideal guard. 
The technology that shapes the artificial intelligence necessary to 
review any given format, declare it safe, and assure the user that it 
was executed properly, is not currently available. 



The DoD MLS Program is developing and deploying guards to 
partially meet common requirements for MLS in the near term. The 
Standard WWMCCS Guard provides a means for DoD 
organizations to extract Secret and less classified data from the Top 
Secret Worldwide Military Command and Control System 
(WWMCCS), which operates in the system-high mode, and to 
make that data available to users on Secret command and control 
systems. The guard reviews all data transfers according to the 
established classification rules to verify that the data passed are not 
classified Top Secret. It handles a wide range of high-to-low and 
low-to-high data transfers, including Time Phased Force and 
Deployment Data, Status of Readiness and Training System data, 
electronic mail, and teleconference messages. The guard has been 
certified and accredited by the Joint Staff for use with WWMCCS. 

The DoD MLS Program is also developing and deploying another 
standard guard to meet common operational requirements in the 
near term— the Standard Mail Guard. The guard allows users of 
existing Secret and Unclassified communities to securely exchange 
Unclassified electronic mail. The guard relies on users to review 
messages before they send them to verify that only Unclassified 
data are exchanged between the Secret community and the 
Unclassified community. 



3.4.3 MLS Workstations 



A workstation is a user terminal with its own processing and 
storage capabilities. It can be linked to a local area network that can 
provide a number of services (e.g. electronic mail, word processing, 
computation, and remote file access). MLS workstations are 
workstations that can separate and protect data of different security 
levels. Compartmented mode workstations (CMW) are the 
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predominate type of MLS workstation and specifically meet the 
requirements set forth by the Defense Intelligence Agency to 
support multilevel and compartmented mode operations of ' 
intelligence analysts. CMWs provide a multilevel, multiwindowing 
capability that permits users to have windows of different security 
levels open simultaneously on their computer screens. This trusted 
multiwindowing capability is a critical element in making MLS 
workstations operationally effective. 



The initial goal of an MLS workstation is to allow a user to access 
systems operating at different security levels simultaneously from a 
single position. The concept involves the MLS workstation with 
two network connections, one for the high side, another for the low 
side. An MLS workstation provides improved capability over a 
guard because it supports full capability usage of both high and low 
existing systems from one workstation. An MLS workstation 
should not affect the existing systems themselves but should 
provide a user enhanced access to the systems. Several current 
development efforts with MLS workstation technology meet these 
operational requirements. 



In MLS workstations, the trusted multiwindowing capability can be 
used to support interaction with multiple systems or application 
software. The trusted workstations allow users to access systems 
and application software at different classification levels 
simultaneously and transfer data between security levels (if the user 
has the appropriate authority). For example, information can be 
transferred from the Secret system to the Top Secret system. 
Information from the Top Secret system can be sanitized or 
downgraded, if necessary, and sent to the Secret system after 
review. The users can also alternate working with both systems 
through the multiple windows. 



The DoD MLS Program is developing and deploying MLS 
workstations not only to bridge different security levels in a 
command and control infrastructure, but also to enhance the data 
communications between intelligence organizations and the 
commands that they support. Using MLS workstations and other 
network security techniques, the program developed the 
OPS/INTEL Interface to facilitate more interaction between 
intelligence analysts and the command staff. The OPS/INTEL 
Interface provides capabilities to intelligence analysts to pull data 
from various intelligence resources, review and, if needed, sanitize 
the data, and electronically pass the data to collateral systems for 
further access and processing. The OPS/INTEL Interface also 
provides a means for requests for intelligence to be sent by 
command staff and electronically received by the intelligence 
analysts. 
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3.4.4 MLS Networks 



A multilevel network is the logical next step to follow the 
installation of multilevel workstations. An MLS network can 
provide secure data communication services among components in 
information systems. MLS networks can interconnect single-level 
and multilevel components on a shared network infrastructure by 
providing sensitivity labels and network security services for the 
data transferred between systems. MLS networks do not need to 
have any MLS hosts or workstations on them to make them 
effective solutions; the MLS networks may simply allow single- 
level hosts and workstations of different security levels to share a 
common infrastructure. 



MLS network components are used for both local area networks 
and wide area networks, which are composed of numerous 
elements, such as cabling, terminal servers, bridges, routers, and 
gateways. In an MLS network, several of these elements are trusted 
to enforce the security policy for the network. 



3.4.5 MLS Data Base Management Systems 

MLS DBMSs provide the management, storage, and retrieval of 
multiple levels of related data, allowing users of different security 
levels to have access to a shared set of data according to their 
individual authorizations. For example, a DBMS server is 
accessible to both the Secret and Top Secret users. Top Secret 
cleared users have access to read the entire data base. Secret cleared 
users are restricted to reading and writing within the confines of the 
Secret portion of the data base. Security mechanisms are in place to 
enforce this policy, including sensitivity labels for various data 
base constructs like tables, views, and records. MLS DBMSs 
manage and control user queries according to the security levels of 
the data and the user clearances. They can eliminate duplication of 
information on separate systems, resulting in more timely, 
consistent, and accurate data. MLS DBMSs will serve as the 
foundation for many applications in MLS systems. 



3.4.6 MLS Systems 
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The ultimate goal of MLS is not simply to interconnect existing 
single-level systems operating at different security levels, or even to 
allow users to perform office automation functions at multiple 
security levels (albeit maintaining separation of data of different 
levels). Rather, the goal is to foster a truly multilevel environment, 
whereby a user can process data of multiple levels in a more 
integral manner. 

Consider, for example, a multilevel document preparation system 
that allows a user to label individual paragraphs and section 
headings with their classifications. This system would accurately 
label pages according to the maximum classification of the 
paragraphs on the pages, and allow cutting and pasting among 
documents while still maintaining sensitivity labels and enforcing 
security rules so that more classified paragraphs are not included in 
less classified reports. 

Another example involves a multilevel data base to direct and 
monitor military transportation, including points and times of 
embarkment and destination, transit route, crew information, and 
cargo information. This data base could be used to direct and track 
missions that are both unclassified and classified. However, 
because some information about the classified missions needs to be 
visible at the unclassified level, the MLS DBMS supporting this 
application would allow classified users to enter and retrieve both 
classified and unclassified data about the missions. By providing 
cover stories so that some information is available at the 
unclassified level, uncleared persons could coordinate for the 
arrival of aircraft requiring specific off-loading equipment. The 
unclassified users of this system could have, then, limited visibility 
into the various missions. 



The goal MLS system combines the MLS hosts, workstations, 
DBMSs, networks, and other components with multilevel 
applications to comprise an integrated multilevel environment 
rather than only a lashing together of multiple single-level 
elements. These MLS systems could be applied to command and 
control, office automation, data fusion, decision support, and other 
uses throughout the DoD. 



MLS DOs AND DONTs 



Current MLS technology is evolving. Even so, the available 
technology is widely applicable to DoD programs, and emerging 
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MLS technology will have an even greater impact. There are several 
concepts to keep in mind and adages to apply when considering 
~ MLS technology and capabilities. 



Do: Integrate INFOSEC engineering into the system life cycle. 
Don't: Think that security can be retrofitted into systems . 

Security planning and other security-related activities must be a 
total life cycle activity. The success of an MLS system development 
or acquisition requires effective security planning beginning with 
the earliest phases of the life cycle. To succeed in implementing 
MLS technology, security must be viewed as an integral functional 
requirement throughout the system acquisition. MLS provides 
capabilities to meet operational requirements while overcoming 
some of the traditional constraints that security imposes on 
information systems. This recognition promotes the effective 
incorporation of security-related activities throughout the entire 
system acquisition life cycle. Retrofitting security features and 
assurances into a system is inefficient and often more costly than it 
would have been to originally include security into the design, 
implementation, and operations. 



Do: Rethink your operational concept to understand how MLS will 
meet and enhance your operational requirements. 

Don't: Buy a solution and then look for a requirement. 



Understanding at the earliest possible time the operational 
requirements of the system and how the system is intended to be 
used will allow for the effective analysis and selection of solutions. 
Many areas need to be examined in defining the requirements. For 
example, the concept of operations addresses the following 
questions: 



What mission is the system to support? What is the function of 
the system? What are the initial and future connections? What is 
the data sensitivity range? Who are the intended users and what 
are their roles? What clearances and authorizations do the users 
have? How can MLS be used to automate the users' jobs? What is 
the flow of information among users and systems? 
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A firm understanding of the operational requirements helps to 
create an effective concept of operations for the system. When the 
operational requirements are understood, MLS capabilities can be 
selected to meet both the operational and security requirements. 
This type of approach considers, we have these requirements, 
therefore which security solution can satisfy them?, instead of an 
approach that questions, that vendor has an MLS widget, now how 
can we use it? 



Do: Identify and involve your accreditors early in the MLS project. 

Don't: Risk the project with your interpretation of ambiguous 
security regulations and policy. 



The accreditor for a system, sometimes known as its Designated 
Approving Authority (DAA), is responsible through policy and 
directive for the security of that system. Therefore, the accreditor 
should be identified and involved in the system acquisition process 
from its initiation. The participation of accreditation authorities in 
the system definition activities will provide them insight into the 
rationale for the security approach chosen. This is especially 
important in an MLS environment where accreditors have few tools 
or methods with which to assess the security solutions 
implemented. No amount of academic rationalization regarding risk 
indexes and levels of trust will be of use for a program manager if 
the accreditor is uncomfortable with the proposed solution. The 
accreditor should be involved with or made aware of design, 
implementation, and operational proposals and decisions 
throughout the system life cycle. Many systems have multiple 
accreditation authorities because the systems have connections with 
other systems and networks. Any such interconnections should be 
identified early in the system concept and requirements stages. 



Do: Approach MLS incrementally. 
Don't: Pick unrealistic near-term goals. 



Program managers should follow workable and proven strategies 
for achieving MLS capabilities. For example, the implementation 
strategy being undertaken by the DoD MLS Program begins with 
the deployment of MLS guards and workstations at the interfaces 
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between systems operating at different security levels in the near 
term, followed with the integration of MLS components to create 
MLS systems in the long term. The DoD MLS Program 
recommends this approach for both new system developments and 
existing system enhancements. The near-term time frame is 
considered as the current fiscal year through the next. The long 
term time frame is thereafter. Users with especially critical 
operational requirements for MLS might choose to pursue more 
aggressive approaches that entail higher costs and greater 
development risks. As time progresses, the foundation MLS 
technology should be able to provide increasing functionality and 
increasing assurances (e.g., levels of trust). 



The DoD MLS Program has demonstrated the usefulness of 
prototyping MLS capabilities before trying to build operational 
capabilities. Prototyping can help validate system security 
requirements, demonstrate feasibility, reduce uncertainty and risk, 
and increase the chances of user acceptance of a new concept of 
operations. Prototyping provides the opportunity to develop a set of 
realistic functional requirements, something useful with an MLS 
system. The opportunity to refine and validate security 
requirements should not be overlooked. 

Whatever the approach, be sure to choose near-term goals that can 
be met, and build incrementally, so that MLS capabilities can be 
integrated as they become available over the years. 



Do: Design and develop MLS capabilities using existing 
technology. 

Don't: Base the success of your project on the hype of the latest 
vendor marketing call. 



The National Security Agency evaluates commercial products and 
certain government technology against the trusted computer system 
evaluation criteria in DoD 5200.28-STD or one of its 
interpretations for networks, DBMSs, or computer subsystems. 
NSA's evaluation investigates not only a product's security features, 
but also the assurances in the product's design and implementation 
that the security is correct and complete. Program managers and 
system integrators can take advantage of NSA's efforts in the design 
and implementation of MLS capabilities that use these trusted 
products. 

The benefits of using evaluated products are typically evident in the 
certification process, when a system undergoes its own security 
assessment to ensure that it satisfies its security requirements and 
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will allow operations with an acceptable level of risk. An evaluated 
product has already undergone elements of that assessment itself, 
and its use in the system may require less effort to facilitate the 
system certification. For example, one can have confidence that a 
product having successfully completed an NSA evaluation meets a 
certain set of the security requirements placed on it as part of an 
MLS system. However, a similar unevaluated product, providing a 
similar set of functional and security services, would bring with it 
no such confidences and would require that the program manager 
assess those security services more comprehensively in the system 
certification process. 

Many vendors, in an effort to advertise their products, make claims 
that the products are designed to meet the criteria of a certain DoD 
5200.28-STD class. Such claims should only be accepted when 
backed by a certificate from the NSA or a listing in the Evaluated 
Products List. 



To allow multilevel processing in the range set of Unclassified 
through Secret, Secret through Top Secret, or Top Secret through 
Top Secret with compartments, current DoD and NSA guidance for 
determining an appropriate level of trust requires a level of 
protection equal to the B2 class. However, most of the MLS 
workstation platforms are evaluated at the Bl class. This results in 
a workstation that can provide much of the needed functionality, 
but not the higher level of assurance associated with a B2 class 
product. This limited selection of higher assurance products 
sometimes leads to the decision to use lower assurance products 
(e.g., Bl class) to meet important operational needs. The result is 
multilevel functionality without the complementary assurances or 
trust******* 

There are other system requirements to consider in addition to the 
security requirements, and a program manager must make trade-offs 
when selecting technology to meet the total set of requirements on 
a system. When MLS is an operational requirement, program 
managers should consider first the set of evaluated products to 
satisfy the requirement. If the set of available, evaluated products 
does not meet the needs, products in evaluation or derived from 
evaluated products (e.g., such as from using a different hardware 
platform or a more recent version of the operating system) should 
be considered. Other products with claims to provide MLS 
capabilities but that are not evaluated or in evaluation should be 
investigated only after evaluated technology has been exhausted. 



Do: Consider information technology standards for MLS solutions. 
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Don't: Accept proprietary solutions without good reason. 



The computer and communications industry has adopted various 
standards that promote interoperability among networked computer 
systems, operating systems, and application software. For example, 
the following standards are significant in the development and 
integration of information systems: 



Portable Operating System Interface for Computer Environments 
(POSIX) for operating system interfaces Government Open 
Systems Interconnection Profile (GO SIP) for network protocols 
Structured Query Language (SQL) for DBMSs X-Windows for 
windowing applications. 

Many MLS products use these standards for the definitions of their 
interfaces. By adhering to these and other industry standards in the 
development of MLS systems, the systems are provided a more 
flexible basis for enhancements and for changes in the system 
platforms (e.g., porting the application software to another 
standards-compliant operating system or DBMS) when the 
selection of products is as limited as it is for MLS technology. This 
flexibility is crucial to mitigate development risks. 



Do: Coordinate with the DoD MLS Program. 

Don't: Ignore the lessons learned and experiences from other MLS 
projects. 



The DoD MLS Program not only manages and sponsors numerous 
MLS projects throughout the DoD, but it also monitors dozens of 
other projects in the DoD and with other government agencies. The 
DoD MLS Program maintains a selection of lesson learned 
documents, technology assessments, and other information to help 
program managers guide the development and operations of systems 
with operational requirements for MLS. In addition to the 
published materials, the DoD MLS Program provides other 
consultation with DoD and other organizations to help them meet 
their MLS needs. 
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Appendix » Acronyms 
Acronym Meaning 

CMW Compartmented Mode Workstation 
COTS Commercial Off-the-Shelf 
DBMS Data Base Management System 
DAA Designated Approving Authority 
DoD Department of Defense 
FY Fiscal Year 

GOSIP Government Open Systems Interconnection Profile 

INFOSEC Information Systems Security 

MLS Multilevel Security 

NSA National Security Agency 

OPS/INTEL Operations/Intelligence 

POSIX Portable Operating System Interface for Computer 
Environments 

SQL Structured Query Language 
TCB Trusted Computing Base 
http://www.totse.com/en/hack/hack_attack/mul tsec.html 



WWMCCS Worldwide Military Command and Control 
System 



Multilevel Security is NOT the Same as Information Security! 

The DOD Multilevel Security Office does not have the final word 
on computer or network security. We do, however, rely on a 
number of security experts as we implement MLS solutions. Our 
goal is to meet operational requirements while managing the 
associated security risks created by linking systems together. 
Sometimes we have had to tell our customers that the technology 
simply isn't available (at their level of cost) to do what they want to 
do. 



Even More Important! 

An Al -evaluated computer system is not infallible. A malicious 
program can crash a "secure" system. To quote from Firewalls and 
Internet Security: Repelling the Wily Hacker, by William R. 
Cheswick and Steven M. Bellovin (Addison-Wesley, 1994): 

In the case of the [Internet] Worm, for example, most of the 
structural safeguards of the Orange Book would have done no good 
at all. At most, a high-rated system would have confined the breach 
to a single security level. But effectively, the Worm 
was a denial-of-service attack, and it matters little if a multilevel 
secure computer is brought to its knees by an unclassified process 
or by a top secret process. Either way, the system would be useless. 

To the best of our knowledge, the text on this page may be freely reproduced and distributed. 
If you have any questions about this, please check out our Copyright Policy. 
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